Purchase Order Matching

ABSTRACT

An approach is provided for using a purchase order system to verify information on invoices. One or more text fields represented in invoice image data are compared to purchase order data from a purchase order system. If the one or more text fields represented in the invoice image data do not match the purchase order data from the purchase order system, then the one or more text fields represented in the invoice image data are designated for special processing. If the one or more text fields represented in the invoice image data match the purchase order data from the purchase order system, then the invoice is designated as verified. The approach also includes the ability for a user to supplement invoice data with additional data, such as codes used by business organizations, and for automatic correction of errors in text fields using data maintained by the purchase order system.

FIELD

Embodiments relate to invoice processing and, more particularly, toautomatically verifying invoice data with data from a purchase ordersystem.

BACKGROUND

The approaches described in this section are approaches that could bepursued, but not necessarily approaches that have been previouslyconceived or pursued. Therefore, unless otherwise indicated, it shouldnot be assumed that any of the approaches described in this sectionqualify as prior art merely by virtue of their inclusion in thissection.

Despite the proliferation of electronic accounting systems, some aspectsof accounting are still performed manually. For example, when a businessorganization issues purchase orders for products or services andreceives invoices from a vendor, the invoices are sometimes manuallyverified. For example, accounting department personnel may access apurchase order system and compare product or service description,quantity and price information on a printed invoice to data stored in apurchase order system. If all of the data matches, then the invoice isapproved for payment and data from the invoice is entered into anaccounting system to enable payment to be made to the vendor. If some ofthe data on the invoice does not match corresponding data in thepurchase order system however, then the invoice is designated asrequiring special processing. Special processing may take many forms,depending upon a particular situation. For example, in a situation wherean invoice indicates that 100 ordered items were delivered, but thepurchase order system indicates that only 80 of the ordered items weredelivered, then payment for delivery of the 80 ordered items may beauthorized, but not for the remaining 20 items not yet delivered. Manualverification of invoices is labor intensive and prone to error.

SUMMARY

An approach for verifying invoices includes retrieving invoice imagedata that represents an invoice. One or more text fields that arerepresented in the invoice image data are obtained from the invoiceimage data. The one or more text fields represented in the invoice imagedata are verified by comparing the one or more text fields to purchaseorder data from a purchase order system. In response to determining thatthe one or more text fields represented in the invoice image data do notmatch the purchase order data from the purchase order system, then theone or more text fields represented in the invoice image data aredesignated for special processing. In response to determining that theone or more text fields represented in the invoice image data match thepurchase order data from the purchase order system, then the invoice isdesignated as verified and user interface data is generated and providedto a client device. When processed at the client device, the userinterface data allows a user to add one or more additional text fieldsto the one or more text fields to generate revised text field data. Therevised text field data is transmitted to an accounting system forprocessing. The approach may be implemented by instructions stored onone or more computer-readable media, by one or more devices, or by oneor more computer-implemented methods.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings:

FIG. 1 is a block diagram that depicts an arrangement for verifyinginvoices.

FIG. 2 is a flow diagram that depicts and approach for automaticallyverifying invoices using purchase order data.

FIGS. 3A-3D depict an example graphical user interface generated byinvoice verification process that allows a user to view informationabout and/or participate in the verification processing.

FIG. 4 is a message ladder diagram that depicts an example exchange ofmessages between the elements of FIG. 1 to verify invoice data.

FIG. 5 depicts an example user interface for managing invoice data.

FIG. 6 is a block diagram that depicts a table of user-specific codedata.

FIG. 7 is a block diagram that depicts a semantic analysis candidatecode table used with semantic analysis.

FIG. 8 is a block diagram that depicts a computer system upon which anembodiment may be implemented.

DETAILED DESCRIPTION

In the following description, for the purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the embodiments. It will be apparent, however, that theembodiments may be practiced without these specific details. In otherinstances, well-known structures and devices are shown in block diagramform in order to avoid unnecessarily obscuring the embodiments.

I. OVERVIEW

II. SYSTEM ARCHITECTURE

III. INVOICE VERIFICATION

IV. SUPPLEMENTING INVOICE DATA

V. CORRECTING INVOICE DATA

VI. IMPLEMENTATION MECHANISMS

I. Overview

An approach is provided for processing invoices that includes the use ofa purchase order system to verify information on the invoices. Invoiceimage data that represents an invoice is received and one or more textfields represented in the invoice image data are obtained. The one ormore text fields represented in the invoice image data are compared topurchase order data from a purchase order system. If the one or moretext fields represented in the invoice image data do not match thepurchase order data from the purchase order system, then the one or moretext fields represented in the invoice image data are designated forspecial processing. If the one or more text fields represented in theinvoice image data match the purchase order data from the purchase ordersystem, then the invoice is designated as verified and the one or moretext fields are transmitted to an accounting system for processing. Thisapproach allows electronic invoice data to be automatically verifiedusing information from a purchase order system, which may reduce theamount of human labor required to verify invoices and reduce the numberof errors. The approach may also reduce costs associated with manualentry of invoice data into accounting systems. The approach alsoincludes the ability for a user to supplement invoice data withadditional data, such as codes used by business organizations. Inaddition, the approach provides for the automatic correction of errorsin the one or more text fields using data maintained by the purchaseorder system.

II. System Architecture

FIG. 1 is a block diagram that depicts an arrangement 100 for verifyinginvoices. Arrangement 100 includes an arrangement 102 of exampleelectronic systems of a business organization and a vendor 104. In thefollowing examples, the business organization is purchasing goods and/orservices from the vendor 104. In the example depicted in FIG. 1, vendor104 includes vendor processes 106 and local storage 108. Vendorprocesses 106 include, for example, a purchase order process forprocessing purchase orders, an invoice process for generating invoices,an inventory management process, etc. Local storage 108 may include anytype of volatile or non-volatile storage that may vary depending upon aparticular implementation. Vendor 104 may include other elements andprocesses, depending upon a particular implementation.

In the example depicted in FIG. 1, arrangement 102 includes a purchaseorder (PO) system 110, an accounting system 112 and a human resources(HR) system 114. Arrangement 102 may include additional elements andprocesses or fewer elements and processes than those depicted in FIG. 1,depending upon a particular implementation and the approaches describedherein are not limited to any particular electronic systems of abusiness organization. PO system 110 includes one or more purchase orderprocesses 116 and local storage 118. Purchase order processes 116 areconfigured to generate purchase orders for goods and/or servicespurchased by the business organization and to allow entry of variousdata related to purchase orders. For example, purchase order processes116 may provide a graphical user interface that allows entry ofinformation pertaining to purchase orders, such as purchase orderinformation, purchase order status information, purchase order approvalinformation, etc. Local storage 118 may include any type of volatile ornon-volatile storage for storing purchase order and other information.Accounting system 112 includes one or more accounting processes 120 andlocal storage 122. Accounting processes 120 are configured to processinvoices and provide for payment of vendor invoices. Accountingprocesses 120 may include a wide variety of other processes, dependingupon a particular arrangement, for example, accounts payable andaccounts receivable processes. HR system 114 includes one or more humanresources processes 124 and local storage 126. Human resources processes124 may include a wide variety of human resources processes that mayvary depending upon a particular implementation and the approachesdescribed herein are not limited to any particular type of humanresources processes.

Arrangement 102 includes an invoice verification system 128 thatincludes an invoice verification process 130, a coding process 132, acorrection process 134 and local storage 136. As described in moredetail hereinafter, invoice verification system 128 is configuredgenerally to verify electronic invoice data using data from PO system110. This may include determining whether particular text fieldsidentified in electronic invoice data are correct with respect to datamaintained by PO system 110. Electronic invoices that have text fieldsthat are determined to be correct by the invoice verification system 128are designated as verified and provided to accounting system 112 forprocessing. Electronic invoices that have text fields that aredetermined to not be correct by invoice verification system 128 aredesignated for special processing. Coding process 132 allows additionaldata to be added to invoice data and correction process 134 allowsincorrect invoice data to be automatically corrected based upon purchaseorder data from purchase order system 110. These processes are eachdescribed in more detail hereinafter. Invoice verification process 130,coding process 132 and correction process 134 are depicted in thefigures and described herein as being separate for purposes ofdiscussion only and these processes may be implemented in any number ofprocesses, including a single process.

As described in more detail hereinafter, data capture process 138 isconfigured to process electronic invoice data, for example, invoiceimage data, and identify one or more text fields represented in theelectronic invoice data. For example, vendor 104 may generate paperinvoices that are scanned, for example, by a scanner or multi-functionperipheral (MFP), to generate electronic invoice data that is providedto data capture process 138. Alternatively, vendor 104 may generateinvoices in electronic form and in this situation, the electronicinvoice data is provided by vendor 104 to data capture process 138.Although depicted in FIG. 1 as a single process for purposes ofexplanation only, data capture process 138 may comprise any number ofprocesses, depending upon a particular implementation. For example, datacapture process 138 may include, as one example, an optical characterrecognition process for converting invoice image data into text data.According to one embodiment, data capture process 138 includes a datacapture engine for identifying text fields in invoice image data. Onesuch example is Abbyy Flexicapture, by ABBYY USA.

The various elements and processes depicted in FIG. 1 may communicatewith each other via direct communications links or via one or more wiredor wireless networks, for example, one or more local area networks(LANs), wide area networks (WANs) or other networks, including theInternet. Communications between the elements depicted in FIG. 1 may bemade using secure communications. In addition, the various elements andprocessed depicted in FIG. 1 may execute on a common computing platformand computing device, or on different computing platforms and computingdevices, depending upon a particular implementation. As one example,data capture process 138 and invoice verification system 128 may beintegrated into PO system 110 and/or accounting system 112. As anotherexample, data capture process 138 and invoice verification system 128may be implemented in a network and accessed as a network service, forexample, as a cloud service or cloud application.

III. Invoice Verification

FIG. 2 is a flow diagram 200 that depicts an approach for automaticallyverifying invoices using purchase order data, according to anembodiment. Reference is also made to elements depicted in FIG. 1. Inthis example, it is presumed that a business entity “ABC” has ordered,from vendor 104, 100 widgets at a price of $1.00 per widget and hasissued a purchase order 140 to vendor 104 for the widgets. Variouselectronic systems of ABC are represented by arrangement 102. Thepurchase order 140 may be in paper form or electronic form. Vendor 104has delivered the 100 widgets to ABC and issued to ABC an invoice forthe 100 widgets. The invoice references ABC's purchase order number andalso identifies the 100 widgets at a price of $1.00 each, a shippingcharge of $5, and a total charge of $105.

In step 202, invoice image data 142 is obtained that represents theinvoice issued by vendor 104. The invoice image data may be generatedbased upon a paper invoice issued by vendor 104 that is then scanned,for example, by a scanner or multi-function peripheral (MFP).Alternatively, vendor 104 may have issued an electronic invoice.

In step 204, text fields are retrieved from the invoice image data. Forexample, data capture process 138 may process the invoice image data 142to retrieve one or more text fields contained in the invoice image data.This may include various types of processing, such as OCR processing anddata capture processing. In this example, data capture process 138identifies text fields in the invoice image data. The particular textfields identified in invoice image data may vary depending upon aparticular implementation and the approaches described herein are notlimited to any particular text fields. Example text fields include,without limitation, vendor name, invoice number, invoice date, purchaseorder number, item name, item quantity, item price, shipping charge,total charge, other line items, etc. Data capture process 138 mayprovide invoice and text field data 144 to the invoice verificationsystem 128.

In step 206, the text fields retrieved from the invoice image data arecompared to purchase order data. This may include comparing valuescontained in text fields to purchase order data from PO system 110. Theinvoice verification system 128 may obtain purchase order data 146 fromPO system 110, for example, by requesting purchase order data 146 forthe purchase order number or invoice number obtained by data captureprocess 138 from the invoice image data 142. The invoice verificationsystem 128 then compares the purchase order data obtained from PO system110 to the values contained in the text fields obtained by the datacapture process 138.

In step 208, a determination is made whether any mismatches existbetween the text fields obtained from the invoice image data and thepurchase order data obtained from the PO system 110. In this example, a“mismatch” may occur when one or more text fields obtained from theinvoice image data do not match corresponding data in the purchase orderdata obtained from the PO system 110. For example, the value of aquantity obtained by data capture process 138 from the invoice imagedata 142 may not match the quantity for the purchase order 140 issued byPO system 110. This may be determined, for example, by comparing thevalue of the quantity obtained by data capture process 138 from theinvoice image data 142 to the quantity for the purchase order 140 asindicated by purchase order data 146. This type of mismatch indicatesthat there is a discrepancy in the quantity of widgets that ABC orderedand for which ABC was invoiced by vendor 104. In some embodiments, amismatch may be determined to exist when at least a specified number ofdata items, i.e., text fields, do not match the corresponding data fromthe PO system 110. In other embodiments, priorities or designations maybe assigned to invoice data and a mismatch determined when one or moretext fields having a specified priority or designation do not matchcorresponding data obtained from the PO system 110. For example, textfields such as quantity, price and total cost may be assigned thehighest priority or be assigned a special designation, so that if any ofthese text fields do not match the corresponding data obtained from thePO system 110, then a mismatch is determined to exist. Other textfields, for example, a general information field or other non-essentialinformation fields may be assigned a lower priority, such that if thesefields do not match the corresponding data obtained from the PO system110, then a mismatch will not necessarily be determined to exit.

The comparing of the text fields retrieved from the invoice image datato the purchase order data may be performed automatically by invoiceverification system 128, for example, by invoice verification process130. FIGS. 3A-3D depict an example graphical user interface generated byinvoice verification process 130 that allows a user to view informationabout and/or participate in the verification processing. FIG. 3A is adiagram that depicts a portion of a graphical user interface thatdisplays a table of invoice data that has been obtained by data captureprocess 138 from invoice image data 142. The table depicted in FIG. 3Aincludes data for multiple invoices and includes, a purchase ordernumber, an invoice number, an invoice date, a total amount and a freightcost. FIG. 3B is a diagram that depicts a table of purchase order datamaintained by PO system 110. The table depicted in FIG. 3B includes datafor multiple purchase orders and includes, a purchase order number, aunit price, a quantity and a total amount. The purchase order data mayalso include a description and part #, although this information is notincluded in the table of FIG. 3B for purposes of explanation. FIG. 3C isa diagram that depicts a matching matrix that is configured to reconcileinvoice data obtained by the data capture process 138 using purchaseorder data from PO system 110. The diagram of FIG. 3C does not includeany results of the reconciliation because reconciliation has not yetbeen requested. In this example, a graphical user interface object inthe form of a Reconcile 302 button is provided. Upon selection of theReconcile 302 button, reconciliation is performed and the results aredisplayed, as depicted in FIG. 3D. In FIG. 3D, the matching matrix hasbeen populated with the results of reconciling invoice data obtained bythe data capture process 138 using purchase order data from PO system110. As depicted in FIG. 3D, no mismatches have been determined for someof the invoices, as indicated by a Match value of “MATCH”. Invoices forwhich one or more data items obtained by data capture process 138 do notmatch purchase order data from PO system 110 have a Match value of “NO”.As described in more detail hereinafter, invoices that are determined tonot have any mismatches, as indicated by the Match value of “MATCH”, areprovided to the accounting system 112 for processing. Invoices that aredetermined to have one or more mismatches, as indicated by the Matchvalue of “NO”, are identified for special processing, as described inmore detail hereinafter.

If, in step 208, a determination is made that no mismatches exist, thenin step 210, systems are updated in response to this determination. Thismay include updating various systems, depending upon a particularimplementation, and the approaches described herein are not limited toupdating any particular type of system. As one example, the invoice data148 obtained from the invoice image data 142 may be provided toaccounting system 112. This eliminates manual entry of invoice data froma printed invoice, which can reduce costs and reduce the likelihood oferrors attributable to manual data entry. As another example, a statusof the purchase order may be updated in the PO system 110, theaccounting system 112, or both the PO system 110 and the accountingsystem 112. As one example, the status of the purchase order may bechanged to “billed”. Accounting system 112 may also make payment 150 tothe vendor 104. The invoice image data may also be provided to theaccounting system 112.

If, in step 208, a determination is made that one or more mismatchesexist, then in step 212, the one or more text fields are designated forspecial processing. This may include, for example, invoice verificationsystem 128 generating and providing to PO system 110 special processingdata 152. Special processing data 152 may identify an invoice and textfields that did not match the corresponding data obtained from the POsystem 110 to allow corrective action to be taken by accountingpersonnel. Example corrective actions include, without limitation,requesting the vendor 104 to issue a corrected invoice, correcting anymismatches on the invoice, or changing purchase order data maintained bythe PO system 110. Other example corrective actions include, withoutlimitation, determining whether a separate purchase order (andcorresponding invoice) should be generated for a portion of goods and/orservices that were received. Corrective action may also include, forexample, generating and transmitting an email or other type of messagenotification to notify one or more recipients that a mismatch exists fora particular invoice. Results of the comparison made in Step 206 may berecorded, for example, in report data stored on local storage 136. Thereport data may indicate that no mismatches were found, or in situationswhere mismatches are identified, the report data may indicate theparticular mismatches that were identified. For example, the report datamay specify particular text fields where mismatches occurred.

FIG. 4 is a message ladder diagram 400 that depicts an example exchangeof messages between the elements of FIG. 1 to verify invoice dataaccording to an embodiment. As in the prior example, this exampleassumes that the business entity ABC has ordered widgets from vendor104. In step 402, ABC generates and provides a purchase order to vendor104. Vendor 104 delivers the widgets to ABC and generates an invoice. Instep 404, invoice image data is provided to ABC and processed by thedata capture process 138. This may occur in several ways, depending uponthe type of invoice generated by the vendor 104. For example, if vendor104 generates a paper invoice, then the paper invoice may be scanned bya scanner or MFP to generate invoice image data. Alternatively, vendor104 may generate and provide to ABC invoice image data. Embodiments arenot limited to situations in which the invoice image data is provideddirectly from vendor 104 to the data capture process 138. Invoice imagedata may be stored on a network service and then retrieved by the datacapture process 138 from the network service. For example, paperinvoices may be scanned and the invoice image data stored at aparticular network service or at a network storage location.Alternatively, vendor 104 may generate invoice image data and cause theinvoice image data to be stored at the particular network service or atthe network storage location. Data capture process 138 then retrievesthe invoice image data from the particular network service or from thenetwork storage location. One example of a network storage location is aparticular server within a business organization.

In step 406, the data capture process 138 processes the invoice imagedata to obtain text fields contained in the invoice image data, aspreviously described herein. In step 408, data capture process 138provides the invoice and text field data to the invoice verificationsystem 128. In step 410, invoice verification system 128 generates andtransmits to PO system 110 a request for PO data. In response to therequest, in step 412, the PO system 110 provides PO data to invoiceverification system 128. The request includes sufficient information forthe PO system 110 to provide the PO data to the invoice verificationsystem 128. For example, the request may include a purchase order numberobtained by the data capture process 138 from the invoice image data instep 406. If the purchase order number is not available, or simply as analternative, it may be possible for the request to use other informationobtained from the invoice image data. For example, information thatidentifies the ordered product or service, quantity and price may beincluded in the request and used by the PO system 110 to identify acorresponding purchase order.

In step 414, mismatches are identified. As previously described herein,invoice verification system 128 compares one or more data in thepurchase order data received from the PO system 110 to the text fielddata obtained by the data capture process 138 to determine whether amismatch exists between the invoice issued by the vendor 104 and thepurchase order data maintained by ABC.

If no mismatches are identified, then in step 416, the invoiceverification system 128 provides invoice data to the accounting system112. The invoice data may include the invoice image data, as well as thetext data, e.g., text fields, obtained by data capture process 138 instep 406. The invoice data does not necessarily have to be provideddirectly from invoice verification system 128 to the accounting system112. For example, invoice verification system 128 may cause the invoicedata to be stored at a particular network service or at a networkstorage location, which may be the same or different than the networkservice or network storage location use to store the invoice image data,as previously described herein. Accounting system 112 then retrieves theinvoice data from the particular network service or from the networkstorage location. In step 418, the accounting system 112 makes a paymentof the invoice to the vendor 104. As previously described herein, in thesituation where no mismatches are identified, then other functionalitymay also be performed. For example, a status of the purchase order maybe updated, e.g., changed to “billed,” in the PO system 110, theaccounting system 112, or both the PO system 110 and the accountingsystem 112. As one example, the status of the purchase order may bechanged to “billed”.

If mismatches are identified, then in step 420, special processing datais generated and provided to the PO system 110. As previously describedherein, the special processing data may identify an invoice and textfields that did not match the corresponding data obtained from the POsystem 110 to allow investigation by accounting personnel.

IV. Supplementing Invoice Data

Invoice verification system 128 may be configured to allow users tomanage invoice data, including adding data to invoice data. The addeddata may replace inaccurate or incomplete invoice data, or maysupplement existing invoice data. For example, the invoice image data142 from vendor 104 or the invoice and text field data 144 from datacapture process 138 may contain inaccurate or incomplete invoice data,or may be missing some invoice data.

According to one embodiment, coding process 132 is configured to providea user interface to manage invoice data 148. FIG. 5 depicts an exampleuser interface 500 for managing invoice data. Coding process 132 maygenerate user interface 500 using a wide variety of techniques that mayvary depending upon a particular implementation. For example, a clientdevice may be configured with a client component that interacts withcoding process 132. As another example, coding process 132 may implementuser interface 500 by one or more Web pages that are provided to a Webbrowser executing on a client device.

User interface 500 may be accessed via a client device that interactswith coding process 132. User interface 500 includes an area 502 withuser interface controls for locating an invoice. The user interfacecontrols allow a user to enter an invoice number and view the invoicestatus as well as details of the invoice in an invoice details area 504.In the present example, a user has entered the invoice number “58-5989”and coding process 132 has obtained and displayed the current invoicestatus “Verified” and details of the invoice in an invoice details area504. The user interface controls in area 502 also include a search tool“Enter Search Criteria:” that allows a user to search for an invoice byentering information that might be contained on an invoice. For example,a user might enter a particular item name and a results box is displayedidentifying invoices that include the particular item name. An enteredinvoice number or other search criteria may be applied against invoicedata stored on local storage 136, or against invoice data stored atanother location external to arrangement 102. For example, an enteredinvoice number or other search criteria may be applied against invoicedata stored in a database accessible by coding process 132 over one ormore networks.

As depicted in FIG. 5, the invoice details displayed in invoice detailsarea 504 include the name and address of the vendor “ABC Company,” aninvoice date, invoice number, item name, quantity ordered, unit price,cost, shipping costs and total cost. The invoice details also includeinformation about the customer, including customer name, address andcustomer number. The invoice details depicted in FIG. 5 are provided forexplanation purposes and embodiments are not limited to the particularinvoice details depicted in FIG. 5.

User interface 500 includes an invoice management area 506 that includescontrols for managing invoice data. In the example depicted in FIG. 5,the controls include Edit Invoice Data 506 a, Delete Invoice Data 506 band Add Invoice Data 506 c. Selecting the Edit Invoice Data 506 acontrol allows a user to edit invoice data in invoice details area 504,for example, by selecting and editing fields in invoice details area504. Selecting the Delete Invoice Data 506 b control allows a user todelete invoice data in invoice details area 504, for example, byselecting and deleting fields in invoice details area 504. Selectingeither the Edit Invoice Data 506 a control or the Delete Invoice Data506 b control may cause additional user interface objects, for exampledialog boxes and user interface controls, to be displayed to provide therequested functionality.

Selecting the Add Invoice Data 506 c control causes area 508 to bedisplayed. Area 508 includes a set of controls 510 for adding variouscodes to invoice data. In the example depicted in FIG. 5, the codesinclude cost codes, location codes and project codes, but theseparticular code types are provided for explanation purposes andembodiments are not limited to these particular codes. In this example,the cost code specifies a cost type or a cost category of the goods orservices purchased. The location code specifies a location of thecustomer, which may refer to an actual physical location of the customeror a logical location associated with the customer, such as a buildingname or an area within a building. The project code specifies a projectof the customer to which the purchased goods or services correspond. Forexample, a particular customer may purchase goods or services formultiple projects and the project code identifies a particular projectof the customer with which the purchased goods and services areassociated or belong. Examples of other codes include, withoutlimitation, Standard Industrial Codes (SICs), project codes, such as CIScodes, other standardized codes and cost codes associated with aparticular industry or business organization. Controls 510 allow a userto select from pull-down lists, a cost code, a location code and aproject code. The code values made available to users in controls 510may be obtained from a code database. The code database may bemaintained by invoice verification system 128 or may be maintained by athird party external to arrangement 102. An Add Codes control 512 causesthe codes selected by the user to be added to the invoice data. Forexample, text data for the codes selected by the user may be added tothe invoice data.

The code values made available in controls 510 may be user specific.That is, the particular code values made available via the pull-downmenus in controls 510 may be selected for a particular user from aplurality of code values. The identity of a user may be established, forexample, when a user accesses coding process 132, e.g., by supplying auser ID to access coding process 132. The selection of code values for aparticular user may be based upon a wide variety of factors that mayvary depending upon a particular implementation and embodiments are notlimited to any particular factors. Example factors include, withoutlimitation, code history of the user, employment duties of the user orpre-specified codes for the user. For example, coding process 132 maymaintain, for each user, a code history that includes the codes ofinvoices that each user accessed via user interface 500 and codespreviously selected by each user via controls 510. Coding process 132may maintain a list of codes for a user based upon the employment dutiesof the user. For example, suppose that a particular user employed byCompany X is responsible for working with vendors for a particular setof products and services purchased by Company X, from a plurality ofproducts and services purchased by Company X. Coding process 132 maymaintain, for the particular user, a list of codes associated with theparticular set of products and services. Pre-specified codes for usersmay include codes that the users are likely to select when accessinginvoice data. Pre-specified codes may be determined, for example, basedupon products and services typically purchased by business organizationsfor which the users are accessing invoice data. Providing user-specificcode values via controls 510 may provide a more favorable userexperience by reducing the number of code values that a user mustnavigate and by eliminating code values that a user is not likely toselect.

FIG. 6 is a block diagram that depicts a table 600 of user-specific codedata. Table 600 includes user-specific code data for three usersidentified in table 600 as “User01”, “User02” and “User03”. Each row oftable 600 corresponds to a particular user and specifies cost code,location code and project code values for the corresponding user. Thevalues in table 600 may be used to populate the pull-down menus incontrols 510.

Area 508 also includes a code search tool 514 that allows a user tosearch for particular codes. For example, a user may enter the term“Foods” into code search tool 514 and search results may be displayed tothe user that include the code “C001 Foods”. Searching for additionalinformation, such as codes, to be added to invoice data may also beachieved using a semantic analysis search. Area 508 includes a control516 for initiating a search for candidate codes using semantic analysis.According to one embodiment, the semantic analysis determines candidatecodes based upon data contained in the invoice data. The semanticanalysis may use text, such as a vendor name, item name, etc., toidentify one or more candidate codes that are presented to the user viaone or more graphical user interface objects.

FIG. 7 is a block diagram that depicts a semantic analysis candidatecode table 700 used with semantic analysis. Each row of table 700includes a column with one or more invoice features and columns for oneor more cost codes, one or more location codes and one or more projectcodes that correspond to the one or more invoice features. The invoicefeatures may be used to search invoice data. According to oneembodiment, the invoice features are used to construct one or morequeries that are processed against invoice data, such as the invoicedata displayed in areas 504. For example, suppose that a user enters aninvoice number in area 502 and invoice details are displayed in invoicedetails area 504. The candidate code values provided in controls 510 maybe obtained by performing a search for invoice features in table 700 andwhen a match is determined, using the corresponding cost codes, locationcodes and projects codes from table 700 to populate the values incontrols 510. For example, if the invoice data displayed in invoicedetails area 504 includes a vendor name of “ABC” or includes the term“Food”, then the cost code, location code and project code from thefirst row of table 700 are used to populate the values in controls 510.More specifically, the Cost Code pull-down menu would include the “C001Foods” cost code, the Location Code pull-down menu would include the“L001 Cupertino” location code and the Project Code pull-down menu wouldinclude the “P0001 Project01” project code.

The use of semantic analysis to identify candidate codes is helpful foridentifying candidate codes that are relevant to a particular invoice,instead of requiring a user to review large numbers of candidate codes,many of which might be unrelated to a particular invoice of interest.For example, referring to the invoice data contained in invoice detailsarea 504, the use of semantic analysis is helpful in identifyingcandidate codes for controls 510 that are relevant to the Widgets-TypeA1 sold by ABC Company to DEF Company. This provides a more favorableuser experience by automatically populating the code values displayed incontrols 510 with code values that are relevant to the invoice datadisplayed in invoice details area 504, namely, Widgets-Type A1 sold byABC Company to customer DEF Company. The use of semantic analysis toidentify candidate codes may be used to identify an exclusive set ofcandidate codes to display in controls 510, meaning that other codes notidentified using semantic analysis will not be included in the pull-downmenus. Alternatively, semantic analysis may be used in other ways.According to one embodiment, the codes identified using semanticanalysis may be included in pull-down menus ahead of, or on top of,other codes. So, although a large number of codes may be made availableto users via pull-down menus, the codes determined using semanticanalysis are presented first in the pull-down menus.

Semantic analysis may also be optionally performed on a user-specificbasis. As depicted in FIG. 7, the data contained in semantic analysiscandidate code table 700 may be organized on a per-user basis. In thisexample, when User01 requests that semantic analysis be used todetermine candidate codes by selecting control 516, the codes in thefirst row of table 700 are used when the invoice features VendorName=“AAA” or the term “Food” is found in the invoice data in invoicedetails area 504. When User02 requests that semantic analysis be used todetermine candidate codes by selecting control 516, the codes in thesecond row of table 700 are used when the invoice features VendorName=“BBB” or the term “Drink” is found in the invoice data in invoicedetails area 504. Note that this approach allows the particular invoicefeatures that are used by semantic analysis to identify candidate codesmay be tailored to a particular user, for example, based upon selectionhistory, employment duties, etc., as previously described herein. Theuse of user-specific semantic analysis may provide further enhancementsto the user experience by further improvements to relevancy to aparticular user.

V. Correcting Invoice Data

In some situations, the invoice and text field data 144 generated bydata capture process 138 may be incomplete or contain errors. This mayoccur for a wide variety of reasons, for example, that the invoice imagedata 142 is missing data, includes incorrect data, or that the invoiceimage data 142 has been corrupted. According to one embodiment, invoiceand text field data 144 may be automatically corrected based uponpurchase order data 146 from PO system 110. For example, suppose thatthe invoice and text field data 144 contains a purchase order numberthat exactly matches a purchase order number maintained by PO system110. This this example, there is an exact match between the purchaseorder number contained in the invoice and text field data 144 and apurchase order number maintained by PO system 110, but embodiments arenot limited to situations in which an exact match occurs. In situationswhere a near match exists, other information from the invoice and textfield data 144 and PO system 110 may be used to confirm that the invoicenumbers are the same. For example, invoice date, item name, itemquantity, etc., from the invoice and text field data 144 may be comparedto corresponding data maintained by PO system to confirm a match ofpurchase order numbers.

Once the invoice and text field data 144 has been positively associatedwith a particular invoice, then information maintained by PO system 110may be used to automatically correct data contained in the invoice andtext field data 144. For example, suppose that invoice and text fielddata 114 includes the vendor name “ABC Company” but that the vendor namemaintained by PO system 110 for that invoice is “A.B.C. Company.” Inthis situation, correction process 134 may automatically change thevendor name from “ABC Company” to “A.B.C. Company” in the invoice data148 provided to accounting system 112. In this example, the replacementof the vendor name may be made in response to any differences existingbetween the vendor name included in the invoice and text field data 144and the vendor name maintained by PO system 110. In other situations,the replacement of the vendor name may be made in response to thedifferences existing between the vendor name included in the invoice andtext field data 144 and the vendor name maintained by PO system 110exceed a specified threshold. Although examples are described herein inthe context of correcting a vendor name in invoice and text field data144, embodiments are not limited to correcting vendor names and any datacontained in invoice and text field data 144 may be corrected using thisapproach.

VI. Implementation Mechanisms

According to one embodiment, the techniques described herein areimplemented by one or more special-purpose computing devices. Thespecial-purpose computing devices may be hard-wired to perform thetechniques, or may include digital electronic devices such as one ormore application-specific integrated circuits (ASICs) or fieldprogrammable gate arrays (FPGAs) that are persistently programmed toperform the techniques, or may include one or more general purposehardware processors programmed to perform the techniques pursuant toprogram instructions in firmware, memory, other storage, or acombination. Such special-purpose computing devices may also combinecustom hard-wired logic, ASICs, or FPGAs with custom programming toaccomplish the techniques. The special-purpose computing devices may bedesktop computer systems, portable computer systems, handheld devices,networking devices or any other device that incorporates hard-wiredand/or program logic to implement the techniques.

For example, FIG. 8 is a block diagram that depicts a computer system800 upon which an embodiment may be implemented. Computer system 800includes a bus 802 or other communication mechanism for communicatinginformation, and a hardware processor 804 coupled with bus 802 forprocessing information. Hardware processor 804 may be, for example, ageneral purpose microprocessor.

Computer system 800 also includes a main memory 806, such as a randomaccess memory (RAM) or other dynamic storage device, coupled to bus 802for storing information and instructions to be executed by processor804. Main memory 806 also may be used for storing temporary variables orother intermediate information during execution of instructions to beexecuted by processor 804. Such instructions, when stored innon-transitory storage media accessible to processor 804, rendercomputer system 800 into a special-purpose machine that is customized toperform the operations specified in the instructions.

Computer system 800 further includes a read only memory (ROM) 808 orother static storage device coupled to bus 802 for storing staticinformation and instructions for processor 804. A storage device 810,such as a magnetic disk or optical disk, is provided and coupled to bus802 for storing information and instructions.

Computer system 800 may be coupled via bus 802 to a display 812, such asa cathode ray tube (CRT), for displaying information to a computer user.An input device 814, including alphanumeric and other keys, is coupledto bus 802 for communicating information and command selections toprocessor 804. Another type of user input device is cursor control 816,such as a mouse, a trackball, or cursor direction keys for communicatingdirection information and command selections to processor 804 and forcontrolling cursor movement on display 812. This input device typicallyhas two degrees of freedom in two axes, a first axis (e.g., x) and asecond axis (e.g., y), that allows the device to specify positions in aplane.

Computer system 800 may implement the techniques described herein usingcustomized hard-wired logic, one or more ASICs or FPGAs, firmware and/orprogram logic which in combination with the computer system causes orprograms computer system 800 to be a special-purpose machine. Accordingto one embodiment, the techniques herein are performed by computersystem 800 in response to processor 804 executing one or more sequencesof one or more instructions contained in main memory 806. Suchinstructions may be read into main memory 806 from another storagemedium, such as storage device 810. Execution of the sequences ofinstructions contained in main memory 806 causes processor 804 toperform the process steps described herein. In alternative embodiments,hard-wired circuitry may be used in place of or in combination withsoftware instructions.

The term “storage media” as used herein refers to any non-transitorymedia that store data and/or instructions that cause a machine tooperation in a specific fashion. Such storage media may comprisenon-volatile media and/or volatile media. Non-volatile media includes,for example, optical or magnetic disks, such as storage device 810.Volatile media includes dynamic memory, such as main memory 806. Commonforms of storage media include, for example, a floppy disk, a flexibledisk, hard disk, solid state drive, magnetic tape, or any other magneticdata storage medium, a CD-ROM, any other optical data storage medium,any physical medium with patterns of holes, a RAM, a PROM, and EPROM, aFLASH-EPROM, NVRAM, any other memory chip or cartridge.

Storage media is distinct from but may be used in conjunction withtransmission media. Transmission media participates in transferringinformation between storage media. For example, transmission mediaincludes coaxial cables, copper wire and fiber optics, including thewires that comprise bus 802. Transmission media can also take the formof acoustic or light waves, such as those generated during radio-waveand infra-red data communications.

Various forms of media may be involved in carrying one or more sequencesof one or more instructions to processor 804 for execution. For example,the instructions may initially be carried on a magnetic disk or solidstate drive of a remote computer. The remote computer can load theinstructions into its dynamic memory and send the instructions over atelephone line using a modem. A modem local to computer system 800 canreceive the data on the telephone line and use an infra-red transmitterto convert the data to an infra-red signal. An infra-red detector canreceive the data carried in the infra-red signal and appropriatecircuitry can place the data on bus 802. Bus 802 carries the data tomain memory 806, from which processor 804 retrieves and executes theinstructions. The instructions received by main memory 806 mayoptionally be stored on storage device 810 either before or afterexecution by processor 804.

Computer system 800 also includes a communication interface 818 coupledto bus 802. Communication interface 818 provides a two-way datacommunication coupling to a network link 820 that is connected to alocal network 822. For example, communication interface 818 may be anintegrated services digital network (ISDN) card, cable modem, satellitemodem, or a modem to provide a data communication connection to acorresponding type of telephone line. As another example, communicationinterface 818 may be a local area network (LAN) card to provide a datacommunication connection to a compatible LAN. Wireless links may also beimplemented. In any such implementation, communication interface 818sends and receives electrical, electromagnetic or optical signals thatcarry digital data streams representing various types of information.

Network link 820 typically provides data communication through one ormore networks to other data devices. For example, network link 820 mayprovide a connection through local network 822 to a host computer 824 orto data equipment operated by an Internet Service Provider (ISP) 826.ISP 826 in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the“Internet” 828. Local network 822 and Internet 828 both use electrical,electromagnetic or optical signals that carry digital data streams. Thesignals through the various networks and the signals on network link 820and through communication interface 818, which carry the digital data toand from computer system 800, are example forms of transmission media.

Computer system 800 can send messages and receive data, includingprogram code, through the network(s), network link 820 and communicationinterface 818. In the Internet example, a server 830 might transmit arequested code for an application program through Internet 828, ISP 826,local network 822 and communication interface 818.

The received code may be executed by processor 804 as it is received,and/or stored in storage device 810, or other non-volatile storage forlater execution.

In the foregoing specification, embodiments have been described withreference to numerous specific details that may vary from implementationto implementation. The specification and drawings are, accordingly, tobe regarded in an illustrative rather than a restrictive sense. The soleand exclusive indicator of the scope of the invention, and what isintended by the applicants to be the scope of the invention, is theliteral and equivalent scope of the set of claims that issue from thisapplication, in the specific form in which such claims issue, includingany subsequent correction.

What is claimed is:
 1. One or more non-transitory computer-readablemedia storing instructions which, when processed by one or moreprocessors, cause: retrieving invoice image data that represents aninvoice; obtaining one or more text fields represented in the invoiceimage data; verifying the one or more text fields represented in theinvoice image data by comparing the one or more text fields representedin the invoice image data to purchase order data from a purchase ordersystem; in response to determining that the one or more text fieldsrepresented in the invoice image data do not match the purchase orderdata from the purchase order system, then designating the one or moretext fields represented in the invoice image data for specialprocessing; and in response to determining that the one or more textfields represented in the invoice image data match the purchase orderdata from the purchase order system, then: designating the invoice asverified, generating and providing to a client device user interfacedata which, when processed at the client device, allow a user to add oneor more additional text fields to the one or more text fields togenerate revised text field data, and transmit the revised text fielddata to an accounting system for processing.
 2. The one or morenon-transitory computer-readable media of claim 1, wherein the one ormore additional text fields include one or more of a cost code, alocation code or a project code.
 3. The one or more non-transitorycomputer-readable media of claim 1, further storing additionalinstructions which, when processed by the one or more processors,causes: storing, as invoice data in association with invoiceidentification data that uniquely identifies the invoice, the one ormore text fields represented in the invoice image data, and generatingand providing to a client device additional user interface data which,when processed at the client device, allow a user to search for andretrieve, based upon the invoice identification data that uniquelyidentifies the invoice, the one or more text fields represented in theinvoice image data.
 4. The one or more non-transitory computer-readablemedia of claim 1, further storing additional instructions which, whenprocessed by the one or more processors, causes: generating andproviding to a client device additional user interface data which, whenprocessed at the client device, allow a user to search for one or morecandidate code values, wherein selection of a particular candidate codevalue from the one or more candidate code values causes the particularcandidate code value to be included in the revised text field data. 5.The one or more non-transitory computer-readable media of claim 1,wherein allowing a user to add one or more additional text fields to theone or more text fields to generate revised text field data includespresenting to the user for selection a plurality of codes that arespecific to the user and in response to a selection by the user of oneor more codes from the plurality of codes that are specific to the user,causing the selected one or more codes to be added to the one or moretext fields to generate the revised text field data.
 6. The one or morenon-transitory computer-readable media of claim 1, further storingadditional instructions which, when processed by the one or moreprocessors, causes: determining, based upon a semantic analysisperformed on the one or more text fields represented in the invoiceimage data, one or more candidate code values, the user interface dataincludes the one or more candidate code values, and processing of theuser interface data at the client device causes the one or morecandidate code values to be displayed as user-selectable options which,when selected, are included in the revised text field data.
 7. The oneor more non-transitory computer-readable media of claim 1, furtherstoring additional instructions which, when processed by the one or moreprocessors, causes: in response to determining that a particular textfield represented in the invoice image data does not match the purchaseorder data from the purchase order system, then automatically correctingthe particular text field based upon corresponding data from thepurchase order system.
 8. The one or more non-transitorycomputer-readable media of claim 1, further storing additionalinstructions which, when processed by the one or more processors,causes: in response to determining that differences between a particulartext field represented in the invoice image data and corresponding datain the purchase order data from the purchase order system exceed athreshold, then automatically correcting the particular text field basedupon corresponding data from the purchase order system.
 9. An apparatuscomprising: one or more processors; and one or more memories storinginstructions which, when processed by the one or more processors, cause:retrieving invoice image data that represents an invoice; obtaining oneor more text fields represented in the invoice image data; verifying theone or more text fields represented in the invoice image data bycomparing the one or more text fields represented in the invoice imagedata to purchase order data from a purchase order system; in response todetermining that the one or more text fields represented in the invoiceimage data do not match the purchase order data from the purchase ordersystem, then designating the one or more text fields represented in theinvoice image data for special processing; and in response todetermining that the one or more text fields represented in the invoiceimage data match the purchase order data from the purchase order system,then: designating the invoice as verified, generating and providing to aclient device user interface data which, when processed at the clientdevice, allow a user to add one or more additional text fields to theone or more text fields to generate revised text field data, andtransmit the revised text field data to an accounting system forprocessing.
 10. The apparatus of claim 9, wherein the one or moreadditional text fields include one or more of a cost code, a locationcode or a project code.
 11. The apparatus of claim 9, wherein the one ormore memories further store additional instructions which, whenprocessed by the one or more processors, causes: storing, as invoicedata in association with invoice identification data that uniquelyidentifies the invoice, the one or more text fields represented in theinvoice image data, and generating and providing to a client deviceadditional user interface data which, when processed at the clientdevice, allow a user to search for and retrieve, based upon the invoiceidentification data that uniquely identifies the invoice, the one ormore text fields represented in the invoice image data.
 12. Theapparatus of claim 9, wherein the one or more memories further storeadditional instructions which, when processed by the one or moreprocessors, causes: generating and providing to a client deviceadditional user interface data which, when processed at the clientdevice, allow a user to search for one or more candidate code values,wherein selection of a particular candidate code value from the one ormore candidate code values causes the particular candidate code value tobe included in the revised text field data.
 13. The apparatus of claim9, wherein allowing a user to add one or more additional text fields tothe one or more text fields to generate revised text field data includespresenting to the user for selection a plurality of codes that arespecific to the user and in response to a selection by the user of oneor more codes from the plurality of codes that are specific to the user,causing the selected one or more codes to be added to the one or moretext fields to generate the revised text field data.
 14. The apparatusof claim 9, wherein the one or more memories further store additionalinstructions which, when processed by the one or more processors,causes: determining, based upon a semantic analysis performed on the oneor more text fields represented in the invoice image data, one or morecandidate code values, the user interface data includes the one or morecandidate code values, and processing of the user interface data at theclient device causes the one or more candidate code values to bedisplayed as user-selectable options which, when selected, are includedin the revised text field data.
 15. The apparatus of claim 9, whereinthe one or more memories further store additional instructions which,when processed by the one or more processors, causes: in response todetermining that a particular text field represented in the invoiceimage data does not match the purchase order data from the purchaseorder system, then automatically correcting the particular text fieldbased upon corresponding data from the purchase order system.
 16. Theapparatus of claim 9, wherein the one or more memories further storeadditional instructions which, when processed by the one or moreprocessors, causes: in response to determining that differences betweena particular text field represented in the invoice image data andcorresponding data in the purchase order data from the purchase ordersystem exceed a threshold, then automatically correcting the particulartext field based upon corresponding data from the purchase order system.17. A computer-implemented method comprising: retrieving invoice imagedata that represents an invoice; obtaining one or more text fieldsrepresented in the invoice image data; verifying the one or more textfields represented in the invoice image data by comparing the one ormore text fields represented in the invoice image data to purchase orderdata from a purchase order system; in response to determining that theone or more text fields represented in the invoice image data do notmatch the purchase order data from the purchase order system, thendesignating the one or more text fields represented in the invoice imagedata for special processing; and in response to determining that the oneor more text fields represented in the invoice image data match thepurchase order data from the purchase order system, then: designatingthe invoice as verified, generating and providing to a client deviceuser interface data which, when processed at the client device, allow auser to add one or more additional text fields to the one or more textfields to generate revised text field data, and transmit the revisedtext field data to an accounting system for processing.
 18. Thecomputer-implemented method of claim 17, wherein allowing a user to addone or more additional text fields to the one or more text fields togenerate revised text field data includes presenting to the user forselection a plurality of codes that are specific to the user and inresponse to a selection by the user of one or more codes from theplurality of codes that are specific to the user, causing the selectedone or more codes to be added to the one or more text fields to generatethe revised text field data.
 19. The computer-implemented method ofclaim 17, further comprising: determining, based upon a semanticanalysis performed on the one or more text fields represented in theinvoice image data, one or more candidate code values, the userinterface data includes the one or more candidate code values, andprocessing of the user interface data at the client device causes theone or more candidate code values to be displayed as user-selectableoptions which, when selected, are included in the revised text fielddata.
 20. The computer-implemented method of claim 17, furthercomprising: in response to determining that a particular text fieldrepresented in the invoice image data does not match the purchase orderdata from the purchase order system, then automatically correcting theparticular text field based upon corresponding data from the purchaseorder system.